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DETAILED ACTION 

1 . The response filed on 3/3/08 has been received and considered. Claims 1-17 are 
presented for examination. 

Claim Objections 

2. The objections to the claims, recited in the 10/1/07 Office Action, not repeated 
below, have been withdrawn in view of the amendments to the claims filed 3/3/08. 

3. Claim 13 is objected to because of the following informalities. Appropriate 
correction is required. 

4. Claim 13, line 9 recites "an action requests", it would be better if written, "an 
action request". 

Claim Rejections - 35 USC §112 

5. The rejections of the claims under 35 U.S.C. 1 1 2, second paragraph recited in 
the 10/1/07 Office Action have been withdrawn in view of the amendments to the claims 
filed 3/3/08. 

Claim Rejections - 35 USC § 102 

6. The following is a quotation of the appropriate paragraphs of 35 U.S.C. 1 02 that 
form the basis for the rejections under this section made in this Office action: 

A person shall be entitled to a patent unless - 
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(a) the invention was known or used by others in this country, or patented or described in a printed 
publication in this or a foreign country, before the invention thereof by the applicant for a patent. 

7. Claims 13, 15 and 16 are rejected under 35 U.S.C. 102(a) as being anticipated 
by Kim et al ("Design and Implementation of Home Network Systems Using UPnP 
Middleware for Networked Appliances", IEEE Transactions on Consumer Electronics, 
Volume 48, Issue 4, Nov 2002, page(s): 963 - 972). 

8. As to Claim 13, Kim et al teaches: computer-readable media having stored 
thereon a software framework of a generic device emulator for execution on a computer 
to provide emulation of an operation of a device within a device connectivity architecture 
consistent with a textual description of the device, wherein the description of the device 
specifies data formats of requests and responses for a set of actions that the device is 
capable of (page 965, column 1 , paragraphs 1 and paragraph 2, lines 5-8; Figures 9 
and 10 and descriptions), the generic device emulator comprising: program code for 
receiving action requests directed to the device within the device connectivity 
architecture (page 965, column 1 , paragraphs 2-4; Section 4, paragraph 3; Figure 10 
and description); program code for checking an action request against the description to 
validate whether the action request matches that of an action specified in the 
description (page 965, column 1, paragraph 4; Figure 2, "Action Invocation" loop; 
section 4.2, paragraph 4, lines 5-6) and program code for performing a default behavior 
producing a response for the action consistent with the data format specified in the 
description, thereby emulating operation of the device for the action (page 965, column 
1, paragraph 4; Figure 2, "Action Invocation" loop, Figure 10, "dataType"). 
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9. As to Claim 15, Kim et al teaches: wherein performing the default behavior 
comprises producing a response message containing a default value consistent with the 
data format of the response specified for the action in the description (page 965, column 
1, paragraph 4; page 967, column 1, paragraph 3; Figure 10, "dataType'). 

10. As to Claim 16, Kim et al teaches: wherein the program code for performing the 
default behavior for the action in which the data format of the request and response has 
a set of input and output parameters corresponding to state variables of the device 
comprises: program code for setting the corresponding state variables of the device to 
values of the respective input parameters contained in the action request (page 968, 
column 2, last sentence); and program code for producing the response with output 
parameters set to values of the corresponding state variables of the device (page 965, 
column 1, paragraph 2, lines 6-8 and paragraph 4). 



Claim Rejections - 35 USC § 103 

1 1 . The following is a quotation of 35 U.S.C. 1 03(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 102 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 

12. Claims 1-3 are rejected under 35 U.S.C. 103(a) as being unpatentable over by 
Kim et al ("Design and Implementation of Home Network Systems Using UPnP 
Middleware for Networked Appliances", IEEE Transactions on Consumer Electronics, 
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Volume 48, Issue 4, Nov 2002, page(s): 963 - 972) in view of Hite et al (US Patent 
7,213,061). 

1 3. As to Claim 1 , Kim et al teaches: a method of generically emulating devices 
communicating through a device connectivity protocol, the method comprising: 
processing in a generic device emulator a description of a device to be emulated in the 
device connectivity protocol, the description specifying a set of actions of the device to 
be emulated (Table 2; page 965, column 1 , paragraph 1 ; Section 4.2, paragraph 1 ; 
Figures 9 and 10 and descriptions); in response to receiving an action request at the 
device emulator per the device connectivity protocol, checking the action request 
against the device description in the device emulator to validate which action out of the 
set of actions specified in the description the action request matches (page 965, column 
1, paragraph 4; Figure 2, "Action Invocation" loop; section 4.2, paragraph 4, lines 5-6); 
upon validating an action to which the action request matches, producing, at the device 
emulator, a default response, the response based on the description such that, through 
the response the device emulator emulates operation of the device to be emulated 
(page 965, column 1, paragraph 4; Figure 2, "Action Invocation" loop). 

14. Kim et al does not expressly teach wherein the device emulator capable of 
emulating more than one device based on device descriptions. 

15. Hite et al teaches a system and method of an Internet control network that 
eliminates or substantially reduces the disadvantages of prior control systems by 
allowing boundaries between the Internet and the control area network to become 
transparent (column 1, lines 28-35) wherein Internet appliances (Figure 1, elements 37- 
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39; column 3, lines 31-48) communicate via a device connectivity protocol in a control 
area network (Figure 1 , element 34; column 5, lines 48-65) and wherein the network 
includes a generic device emulator capable of emulating more than one device based 
on device descriptions (column 6, lines 5-8, 22-27 and lines 33-40). 

16. Kim et al and Hite et al are analogous art since they are both directed to 
emulating appliances in a device connectivity protocol. 

1 7. It would have been obvious to one or ordinary skill in the art at the time the 
invention was made to modify the device emulator as taught in Kim et al to be a generic 
device emulator capable to emulating more than one device based on device 
descriptions as taught in Hite et al since Hite et al teaches a system and method of an 
Internet control network that eliminates or substantially reduces the disadvantages of 
prior control systems by allowing boundaries between the Internet and the control area 
network to become transparent (column 1 , lines 28-35). 

18. As to Claim 2, Kim et al as modified by Hite et al teaches: wherein producing the 
default response comprises producing a response message containing a default value 
consistent with a data type specified for a return parameter of the action in the 
description (Kim et al: page 965, column 1, paragraph 4; page 967, column 1, 
paragraph 3; Figure 10, "dataType"). 

19. As to Claim 3, Kim et al as modified by Hite et al teaches: wherein the validated 
action has a set of input and output parameters corresponding to state variables of the 
device (Kim et al: page 965, column 1 , paragraph 4section 4.2, paragraph^, last 
sentence, "in the action services, the values of the state variables are changed by the 
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user") and wherein producing the default response comprises: setting the corresponding 
state variables of the device to values of the respective input parameters contained in 
the action request (Kim et al: page 968, column 2, last sentence); producing a response 
with output parameters set to values of the corresponding state variables of the device 
(Kim et al: page 965, column 1, paragraph 2, lines 6-8 and paragraph 4); and producing 
an eventing message if the action modified any evented variables (Kim et al: page 965, 
column 1, paragraph 4; page 967, column 2, last sentence). 

20. Claims 4 and 5 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Kim et al in view of Hite et al as applied to claim 1 above, further in view of Kumar et al 
(US Patent 7,017,148). 

21 . Kim et al as modified by Hite et al teaches processing in a device emulator a 
description of a device to be emulated in a device connectivity protocol, the description 
specifying a set of actions of the device to be emulated, validating in the device 
emulator which action out of the set of actions specified in the description the action 
request matches and upon this validation, producing a default response at the device 
emulator. 

22. Kim et al as modified by Hite et al does not expressly teach (claim 4) providing 
hooks to interface user-provided action response implementations, if any, for the set of 
actions; upon validating the action request to match the action, first checking whether 
there is a user provided action response implementation for the action; producing the 
default behavior response consistent with the description of there is no user-provided 
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action response implementation and otherwise performing the user-provided action 
response implementation for the action; (claim 5) wherein the hooks interface user- 
provided action response implementation of at least one action out of the set of actions 
but not every action out of the set of actions. 

23. Kumar teaches a method and apparatus for UPnP device code generation that 
provides a time and cost effective solution for developing UPnP devices by eliminating 
stages of the software development cycle and allows the device developer to focus their 
attention on application-specific problems instead of worrying about UPnP (column 23, 
lines 13-34), wherein hooks are provided to interface user-provided action response 
implementations of at least one action out of the set of actions, but not every action out 
of the set of actions (column 6, line 28-column 7, line 1 4) wherein the developer is only 
required to write the portion of code to handle a particular function or event (user- 
provided action response implementation) while the code to handle the underlying 
UPnP functionality is automatically generated (default behavior). 

24. Kim et al as modified by Hite et al and Kumar are analogous art since they are 
both directed to UPnP devices and their XML descriptions. 

25. It would have been obvious to one of ordinary skill in the art at the time the 
invention was made to modify the method of processing of a description in a device in a 
device connectivity protocol to produce a default response to emulate a device in a 
connectivity protocol as taught in Kim et al as modified by Hite et al to provide hooks to 
interface user-provided action response implementations as taught in Kumar since 
Kumar teaches a method and apparatus for UPnP device code generation that provides 
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a time and cost effective solution for developing UPnP devices by eliminating stages of 
the software development cycle and allowing the device developer to focus their 
attention on application-specific problems instead of worrying about UPnP (column 23, 
lines 13-34). Further, it would have been obvious to one of ordinary skill in the art at the 
time the invention was made that the processing of the description document for a 
UPnP device as taught by Kim et al as modified by Hite et al (Kim et al: Section 4.2, 
paragraph 1; Figures 9 and 10 and descriptions) would determine if there is a user- 
provided action response and produce the default response if there is no user-provided 
action response implementation or otherwise perform the user-provided action response 
implementation for the action since the description document will be processed in the 
same way regardless of how the actions have been specified. The processing will 
determine which action out of the set of actions in the description document matches 
the action request and perform the matching behavior whether it is a default behavior or 
a user-defined behavior. 

26. Claims 6, 7 and 9 are rejected under 35 U.S.C. 103(a) as being unpatentable 
over Kim et al as modified by Hite et al as applied to claim 1 above, and further in view 
of Skingsley et al (US Patent 6,697,751 ). 

27. Kim et al as modified by Hite et al teaches the testing of emulated devices in a 
device connectivity protocol (Kim et al Figure 15). 

28. Kim et al as modified by Hite et al does not expressly teach (claim 6) applying a 
defect behavior to messages produced to emulate the device in the device connectivity 
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protocol; (claim 7) wherein the defect behavior is applied to packets of a particular type; 
(claim 9) and randomly applying a defect behavior out of a set of defect behaviors to 
messages produced to emulated the device in the device connectivity protocol. 

29. Skingsley et al teaches an apparatus for testing and/or monitoring the 
transmission of data packets by communications equipment including an emulator that 
simulates a variety of network conditions for a variety of packets that embed a range of 
protocols and over a range of types of networks (column 12, lines 31-33) that subjects 
packets to errors thereby allowing applications to review their methods for handling 
such network interruptions which is valuable since present methods of testing network 
software may not expose potential failures (column 12, lines 38-43), wherein (claim 10) 
the emulator (); (claims 6, 7) applies defect behavior to messages produced to emulate 
the device in the device connectivity protocol, wherein the defect behavior is applied to 
the packet of a particular type (column 4, lines 1 -1 2; column 1 2, lines 31 -41 ; column 1 2, 
lines 50-60; column 13, lines 51-61); and (claim 9) and randomly applying a defect 
behavior out of a set of defect behaviors to messages produced to emulate the device 
in the device connectivity protocol (column 13, lines 63-66). 

30. Kim et al as modified by Hite et al and Skingsley et al are analogous art since 
they are both directed to the testing of network devices in a device communications 
protocol. 

31 . It would have been obvious to one of ordinary skill in the art at the time the 
invention was made to modify the testing of emulated devices in a device connectivity 
protocol as taught by Kim et al as modified by Hite et al to include applying defect 
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behavior to messages produced to emulate the device in the device connectivity 
protocol, wherein the defect behavior is applied to packets of a particular type, and 
randomly applying a defect behavior out of a set of defect behaviors to messages 
produced to emulated the device in the device connectivity protocol as taught in 
Skingsley et al since Skingsley et al teaches an apparatus for testing and/or monitoring 
the transmission of data packets by communications equipment including an emulator 
that simulates a variety of network conditions for a variety of packets that embed a 
range of protocols and over a range of types of networks (column 1 2, lines 31 -33) that 
subjects packets to errors thereby allowing applications to review their methods for 
handling such network interruptions which is valuable since present methods of testing 
network software may not expose potential failures (column 12, lines 38-43). 

32. Claim 14 is rejected under 35 U.S.C. 103(a) as being unpatentable over Kim et 
al as applied to claim 1 3 above, in view of Kumar et al. 

33. Kim et al teaches processing in a device emulator a description of a device to be 
emulated in a device connectivity protocol, the description specifying a set of actions of 
the device to be emulated, validating in the device emulator which action out of the set 
of actions specified in the description the action request matches and upon this 
validation, producing a default response at the device emulator. 

34. Kim et al does not expressly teach (claim 14) providing hooks to interface user- 
provided action response implementations, if any, for the set of actions; upon validating 
the action request to match the action, first checking whether there is a user provided 
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action response implementation for the action; producing the default behavior response 
consistent with the description of there is no user-provided action response 
implementation and otherwise performing the user-provided action response 
implementation for the action. 

35. Kumar teaches a method and apparatus for UPnP device code generation that 
provides a time and cost effective solution for developing UPnP devices by eliminating 
stages of the software development cycle and allows the device developer to focus their 
attention on application-specific problems instead of worrying about UPnP (column 23, 
lines 13-34), wherein hooks are provided to interface user-provided action response 
implementations of at least one action out of the set of actions, but not every action out 
of the set of actions (column 6, line 28-column 7, line 14) wherein the developer is only 
required to write the portion of code to handle a particular function or event (user- 
provided action response implementation) while the code to handle the underlying 
UPnP functionality is automatically generated (default behavior). 

36. Kim et al and Kumar are analogous art since they are both directed to UPnP 
devices and their XML descriptions. 

37. It would have been obvious to one of ordinary skill in the art at the time the 
invention was made to modify the method of processing of a description in a device in a 
device connectivity protocol to produce a default response to emulate a device in a 
connectivity protocol as taught in Kim et al to provide hooks to interface user-provided 
action response implementations as taught in Kumar since Kumar teaches a method 
and apparatus for UPnP device code generation that provides a time and cost effective 
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solution for developing UPnP devices by eliminating stages of the software 
development cycle and allowing the device developer to focus their attention on 
application-specific problems instead of worrying about UPnP (column 23, lines 13-34). 
Further, it would have been obvious to one of ordinary skill in the art at the time the 
invention was made that the processing of the description document for a UPnP device 
as taught by Kim (Section 4.2, paragraph 1; Figures 9 and 10 and descriptions) would 
determine if there is a user-provided action response and produce the default response 
if there is no user-provided action response implementation or otherwise perform the 
user-provided action response implementation for the action since the description 
document will be processed in the same way regardless of how the actions have been 
specified. The processing will determine which action out of the set of actions in the 
description document matches the action request and perform the matching behavior 
whether it is a default behavior or a user-defined behavior. 

38. Claim 8 is rejected under 35 U.S.C. 103(a) as being unpatentable over Kim et al 
as modified by Hite et al, further in view of Skingsley et al as applied to claim 6 above, 
and further in view of Kumar and UPnP Implementers Corporation ("UPnP Device 
Certification Process Document", Version 1.0, 2001), herein referred to as UPnPIC. 

39. Kim et al as modified by Hite et al further in view of Skingsley et al teach applying 
a defect behavior to messages produced to test an emulated UPnP device in a device 
connectivity protocol. 
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40. Kim et al as modified by Hite et al further in view of Skingsley et al do not 
expressly teach wherein applying the defect behavior comprises invoking a user- 
provided implementation of the defect behavior. 

41 . Kumar teaches a method and apparatus for UPnP device code generation that 
provides a time and cost effective solution for developing UPnP devices by eliminating 
stages of the software development cycle and allows the device developer to focus their 
attention on application-specific problems instead of worrying about UPnP (column 23, 
lines 13-34), wherein user-provided action response implementations are added to the 
device description (column 6, line 27-column 7, line 14) wherein the developer is only 
required to write the portion of code to handle a particular function or event (user- 
provided action response implementation) while the code to handle the underlying 
UPnP functionality is automatically generated (default behavior). 

42. UPnPIC teaches the UPnP certification process that is used to determine if a 
device complies with the applicable UPnP standard wherein compliance indicates that 
different devices from different vendors support the same device standard and are 
interchangeable with respect to that standard (section 3.1, paragraph 1) wherein the 
certification testing of a UPnP device necessary to achieve certification includes 
protocol, syntax tests and semantic tests (section 5.1 , paragraph 1 ; Figure 4), wherein 
the syntax tests are derived from the device descriptions with added annotations for 
testing (Figure 5; section 5.2, last paragraph, second bullet). 
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43. Kim et al as modified by Hite et al further in view of Skingsley et al, Kumar and 
UPnPIC are analogous art since they are both to UPnP devices and their device 
descriptions. 

44. It would have been obvious to one of ordinary skill in the art at the time the 
invention was made to modify the application of defect behaviors to messages 
produced by emulated UPnP devices in a device connectivity protocol as taught in Kim 
et al as modified by Hite et al further in view of Skingsley et al to include adding user- 
provided implementations of device behaviors as taught in Kumar, wherein the user- 
provided implementation of the device behaviors would include such behaviors as 
defect behaviors, added to the device description for testing purposes as taught in 
UPnPIC, since the addition of user-provided defect behaviors in a device description for 
a UPnP device that is emulated in a device connectivity protocol would allow a device 
developer to study how the device functions in the presence of certain errors in its 
description and how errors will effect the device's communication with other devices in a 
network. 

45. Claims 1 0-1 2 are rejected under 35 U.S.C. 1 03(a) as being unpatentable over 
Skingsley et al in view UPnPIC. 

46. Skingsley et al teaches an apparatus for testing and/or monitoring the 
transmission of data packets by communications equipment including an emulator that 
simulates a variety of network conditions for a variety of packets that embed a range of 
protocols and over a range of types of networks (column 12, lines 31-36) wherein (claim 
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10) the emulator reads a defect configuration representing a defect behavior to be 
applied to a type of packet transmitted from an emulated device per a device 
connectivity protocol (column 4, lines 1-12; column 12, lines 38-41 and 56-58; column 
1 3, lines 63-66; Figure 7); applying the defect behavior to the packet of a particular type 
before transmitting the packet (column 12, lines 56-58; column 13, lines 51-61); 
transmitting the packets as modified by applying the defect behavior (column 12, lines 
58-60); (claim 12) and randomly applying a defect behavior out of a set of defect 
behaviors to messages produced to emulate the device in the device connectivity 
protocol (column 13, lines 63-66). 

47. Skingsley et al does not expressly teach (claim 10) the defect configuration that 
represents a defect behavior being represented in a device defect configuration file, the 
defect behavior represented in a tagged text format, (claim 1 1) wherein applying the 
defect behavior comprises invoking a user-provided implementation of the defect 
behavior. 

48. UPnPIC teaches the certification testing of a UPnP device that includes protocol, 
syntax tests and semantic tests (section 5.1 , paragraph 1 ; Figure 4), wherein the test 
tool includes the protocol tests that are generated from the UPnP device architecture, 
syntax tests that are derived from the device descriptions with added annotations for 
testing, and semantic tests specified by the Working Committees (WC's) that may test 
combinations of states and actions, for example, to test if a VCR properly responds with 
an error to a specific action (Figure 5; section 5.2, last paragraph and bullets). UPnP 
further teaches that device descriptions are written in XML and that UPnP technology 
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uses Internet components including IP, TCP, UDP, HTTP and XML (section 1, 
paragraph 2; section 2.1 ). It is understood by the Examiner that in order for the VCR to 
respond with an error message, it must be written in the VCR's device description that 
an "error" message must be generated in response to the play button being pushed 
when a tape is not loaded in the VCR (page 15, bullet 3). Therefore, in order for this 
behavior of the VCR to be tested, a test that produces this "defect" behavior, wherein 
the play button is pushed when there is no tape in the VCR, must be read and applied 
to the VCR in order to test the device, therefore, a "device defect configuration file" is 
read that represents a "defect behavior" to be applied. Further, it is understood that the 
device descriptions, written in XML are in a tagged text format and that the protocol 
testing of the device occurs by sending test packets over the IP network using UPnP 
protocol from the test node to the UPnP device being tested as shown in Figure 4. 
Finally, it is understood that the device descriptions are "annotated" by a user. 

49. Skingsley et al and UPnPIC are analogous art since they are both directed to the 
testing of a device in a device connectivity protocol. 

50. It would have been obvious to one of ordinary skill in the art at the time the 
invention was made to modify the application of a defect behavior to packets 
transmitted between networked computer components via a device connectivity protocol 
as taught in Skingsley et al to include reading a device defect configuration file, wherein 
the defect behaviors are represented in a tagged text format and wherein the defect 
behaviors are user-implemented as taught by UPnPIC since UPnPIC teaches the 
testing of devices in a device connectivity protocol wherein the devices are described in 
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XML descriptions that can be annotated for testing wherein it would be beneficial for the 
device developer to annotate the behaviors of a device under test to determine how the 
device will function in a network connectivity protocol in response to the invocation of 
particular behaviors such as behaviors that may invoke defects in the device. 

51 . Claim 17 is rejected under 35 U.S.C. 103(a) as being unpatentable over Kim et al 
as applied to claim 13 above, in view of Skingsley et al, further in view of UPnPIC. 

52. Kim et al teaches the testing of emulated devices in a device connectivity 
protocol (Figure 15), wherein the emulated devices are UPnP devices described in XML 
tagged text (Figure 10). 

53. Kim et al does not expressly teach reading a device defect configuration file 
representing at least one defect behavior to be applied to a type of packet transmitted 
from the emulated device within the device connectivity architecture, applying the defect 
behavior to the packet of the particular type and transmitting the packet from the 
emulated device as modified by the defect behavior. 

54. Skingsley et al teaches an apparatus for testing and/or monitoring the 
transmission of data packets by communications equipment including an emulator that 
simulates a variety of network conditions for a variety of packets that embed a range of 
protocols and over a range of types of networks (column 12, lines 31-33) that subjects 
packets to errors thereby allowing applications to review their methods for handling 
such network interruptions which is valuable since present methods of testing network 
software may not expose potential failures (column 12, lines 38-43), wherein (claim 10) 
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the emulator reads a defect configuration representing a defect behavior to be applied 
to a type of packet transmitted from an emulated device per a device connectivity 
protocol (column 4, lines 1-12; column 12, lines 31-36; column 12, lines 56-58; column 
13, lines 51-61); applying the defect behavior to the packet of a particular type before 
transmitting the packet (column 12, lines 56-58); and transmitting the packets as 
modified by applying the defect behavior (column 12, lines 58-60); (claim 11) and 
randomly applying a defect behavior out of a set of defect behaviors to messages 
produced to emulate the device in the device connectivity protocol (column 13, lines 63- 
66). 

55. Kim et al and Skingsley et al are analogous art since they are both directed to the 
testing of network devices in a device communications protocol. 

56. It would have been obvious to one of ordinary skill in the art at the time the 
invention was made to modify the testing of an UPnP emulated device in a device 
connectivity protocol as taught in Kim et al to include reading a defect configuration 
representing a defect behavior to be applied to a type of packet transmitted from the 
emulated device per the device connectivity protocol, applying the defect behavior to 
the packet, and transmitting the packet from the emulated device as modified by 
applying the defect behavior as taught in Skingsley et al since Skingsley et al teaches 
an apparatus for testing and/or monitoring the transmission of data packets by 
communications equipment including an emulator that simulates a variety of network 
conditions for a variety of packets that embed a range of protocols and over a range of 
types of networks (column 12, lines 31-33) that subjects packets to errors thereby 
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allowing applications to review their methods for handling such network interruptions 
which is valuable since present methods of testing network software may not expose 
potential failures (column 12, lines 38-43). 

57. Kim et al as modified by Skingsley et al do not expressly teach the defect 
configuration that represents a defect behavior being represented in a device defect 
configuration file. 

58. UPnPIC teaches the certification testing of a UPnP device that includes protocol, 
syntax tests and semantic tests (section 5.1 , paragraph 1 ; Figure 4), wherein the test 
tool includes the protocol tests that are generated from the UPnP device architecture, 
syntax tests that are derived from the device descriptions with added annotations for 
testing, and semantic tests specified by the Working Committees (WC's) that may test 
combinations of states and actions, for example, to test if a VCR properly responds with 
an error to a specific action (Figure 5; section 5.2, last paragraph and bullets). It is 
understood by the Examiner that in order for the VCR to respond with an error 
message, it must be written in the VCR's device description that an "error" message 
must be generated in response to the play button being pushed when a tape is not 
loaded in the VCR (page 1 5, bullet 3). Therefore, in order for this behavior of the VCR to 
be tested, a test that produces this "defect" behavior, wherein the play button is pushed 
when there is no tape in the VCR, must be read and applied to the VCR in order to test 
the device, therefore, a "device defect configuration file" is read that represents a 
"defect behavior" to be applied. 
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59. Kim et al as modified by Skingsley et al and UPnPIC are analogous art since 
they are directed to the testing of a device in a device connectivity protocol. 

60. It would have been obvious to one of ordinary skill in the art at the time the 
invention was made to modify the application of a defect behavior to packets 
transmitted between networked computer components via a device connectivity protocol 
as taught in Kim et al as modified by Skingsley et al to include reading a device defect 
configuration file as taught by UPnPIC since UPnPIC teaches the testing of devices in a 
device connectivity protocol wherein the devices are described in XML descriptions that 
can be annotated for testing wherein it would be beneficial for the device developer to 
annotate the behaviors of a device under test to determine how the device will function 
in a network connectivity protocol in response to the invocation of particular behaviors 
such as behaviors that may invoke defects in the device. 



Response to Arguments 

61 . Applicant's arguments with respect to claim 1 have been considered but are moot 
in view of the new ground(s) of rejection. Specifically, Applicant argues that Kim's 
appliance emulators do not teach or suggest "processing, in a generic device emulator 
able to emulate more than one device based on a device description, a description of a 
device to be emulated" (pages 1 0 and 1 1 ). The Examiner would like to note that 
although the claim sets forth "a generic device emulator able to emulate more than one 
device based on device descriptions", the claim only sets forth that the generic device 
emulator processes "a description of a device", therefore, only emulating one specific 
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device. Further, the McKim reference sets forth that the appliance emulators can be 
operated on a UPnP-enabled embedded device or PC using a Linux or WinCE platform 
(section 4.2, paragraph 1). It is understood that an "emulator" will emulate any device 
according to whatever device description it is programmed to implement, in this case, 
the UPnP-enabled device or PC are programmed to emulate each appliance, therefore, 
making the emulator "generic". While the Examiner believes that the McKim reference 
does teach or suggest "processing in a generic device emulator able to emulate more 
than one device based on device descriptions", the Hite et al reference has been cited 
to show this claim limitation as taught in the prior art. 

62. Applicant argues that Kim's "appliance emulators" do not check against a 
description to operate since each only uses descriptions to advertise their operations 
and therefore, do not teach or suggest "checking the action request against the device 
description in the device emulator to validate which action" (pages 1 0-1 1 ). McKim 
teaches that the "...appliance emulators can be operated on a UPnP-enabled 
embedded device or PC using a Linux or WinCE platform" (section 4.2, paragraph 1, 
lines 5-8). Therefore, it is the Examiner's understanding that the device descriptions of 
the appliance emulators are "processed". Further, McKim teaches "checking the action 
request against the device description in the device emulator to validate which action 
out of the set of actions specified in the description the action request matches" (page 
965, column 1 , paragraph 4; Figure 2, "Action Invocation" loop) wherein a message is 
sent to invoke an action in the appliance after the user invokes an action service, and 
when the action is successful, the updated state variables are displayed. It is the 
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Examiner's position that the "action service" is the "action request". This "action request" 
is "sent to invoke the action" which "checks the action request against the device 
description in the device emulator to validate which action out of the set of actions 
specified in the description the action request matches", and that the "successful" result 
of updated state variables shows that the proper action requested was found in the 
device description, thereby allowing the action to take place which would update the 
variables as a result. 

63. Applicant's arguments with respect to claim 10 have been considered but are 
moot in view of the new ground(s) of rejection. Applicants arguments regarding 
Skingsley not teaching or suggesting a "device defect configuration file" (page 13) refer 
to limitations that have been amended into the claim and are treated with prior art as 
cited above. Applicant also recites that Skingsley "does not at all discuss how it chooses 
which effects to apply to the packets to emulate network errors" (page 14). The 
Examiner notes, however, that the language of claim 10 does not recite any "choosing" 
of a defect behavior to apply to a packet. 

Conclusion 

64. The prior art made of record and not relied upon is considered pertinent to 
applicant's disclosure. 

65. Shue et al (US Patent 6,862,564) teaches a system and method for providing an 
emulated network including a plurality of emulated networking devices, wherein one 
emulator machine executes various numbers of network node executable images. 
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66. Theobald (US Patent 5,864,658) teaches verifying the conformity of a device 
under test with a standard application protocol wherein a test apparatus emulates 
devices to be controlled and interrogated by the device under test. 

67. Applicant's amendment necessitated the new ground(s) of rejection presented in 
this Office action. Accordingly, THIS ACTION IS MADE FINAL. See M PEP 

§ 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 
CFR 1.136(a). 

A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply is filed within 
TWO MONTHS of the mailing date of this final action and the advisory action is not 
mailed until after the end of the THREE-MONTH shortened statutory period, then the 
shortened statutory period will expire on the date the advisory action is mailed, and any 
extension fee pursuant to 37 CFR 1 .136(a) will be calculated from the mailing date of 
the advisory action. In no event, however, will the statutory period for reply expire later 
than SIX MONTHS from the date of this final action. 

68. Any inquiry concerning this communication or earlier communications from the examiner 
should be directed to Mary C. Jacob whose telephone number is 571-272-6249. The examiner 
can normally be reached Tuesday-Thursday, 7AM-4PM. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Paul Rodriguez can be reached on 571-272-3753. The fax phone number for the 
organization where this application or proceeding is assigned is 571-273-8300. 
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Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private 
PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). 

/Mary C Jacob/ 
Examiner, Art Unit 2123 
/M. C. J./ 
5/6/08 

/Paul L Rodriguez/ 
Supervisory Patent Examiner, 
Art Unit 2123 



